Field of the Invention
The present invention relates to an intermediate network entity for controlling bandwidth for an adaptive bit rate (ABR) stream, for example, a HTTP adaptive video stream, being downloaded from a content server to a client.
Description of the Related Technology
Adaptive Bit Rate (ABR) streaming, for example, Hyper Text Transfer Protocol (HTTP) Adaptive Video Streaming (AVS), is a known technique used to stream video (and/or other content) over the Internet and other communications networks. In order to support ABR streaming, typically, a video server, in a communication network, makes available for download multiple variants of the same video content, each variant having one or more characteristics associated therewith that are different to those of the other versions. For example, the one or more characteristics may relate to video quality, as indicated, for example, by bit rate, or resolution that is being used.
Each variant is sub divided into a plurality of consecutive smaller multi-seconds parts known as segments or chunks. Each segment is typically between 2 to 10 seconds of duration. The video server also makes available a so called manifest file which contains information (e.g. meta-data) describing each and every available segment which is to be used by a client device in order to play back segments. A manifest file also contains a different pointer to or an address (typically a Uniform Resource Locator (URL)) for each segment of each variant of the video content, or alternatively, a different pointer to an address (again typically a URL) for each version of the video content and a byte range for each different segment within each version. This segment pointer information enables a client device to individually request segments from the server.
Prior to downloading desired ABR video content from the video server, a client device first downloads the manifest file for that video content and uses the manifest file to identify the different available versions of the video content. Based on the information in the manifest file, the client sends sequential HTTP requests for segments of the video content, the segments being of the variant that has a quality level most appropriate for the download bandwidth currently available to the client device.
Typically, in ABR streaming, a HTTP GET request will only be issued by a client device for the next segment in the sequence when the complete previous segment has been received in a HTTP RESPONSE corresponding to the previous HTTP GET request.
The client device continuously monitors the available download bandwidth and if it finds that the bandwidth has deteriorated to an extent that it is now too low for the variant of the segments currently being downloaded, the client device starts to request the next segments for displaying the video content from a lower quality variant (if available). Conversely, if it finds that the bandwidth has improved to an extent that it can accommodate a higher quality variant than that of the segments currently being downloaded, the client device starts to request the next segments for displaying the video content from a higher quality variant (if available).
Accordingly, ABR streaming enables a user device to dynamically select the best available stream according to network throughput. Requesting segments one after the other at possibly different resolutions can result in a smoother video experience for a user even if the available bandwidth varies.
Current proprietary implementations of ABR streaming include Microsoft's ‘Smooth Streaming’ implemented by its Silverlight player, Apple's ‘HTTP Adaptive BitRate Streaming’ implemented in its desktop and mobile products, and Adobe's ‘HTTP Dynamic Streaming’ implemented by its Flash player (v10.1 and later). All three of these implementations support H.264 as a video codec and Advanced Audio Coding (AAC) as an audio codec.
In addition, the standards body 3GPP has defined its standard ‘Dynamic Adaptive Streaming over HTTP’ and the standards body MPEG its standard ‘Dynamic Adaptive HTTP Streaming’.
An intermediate network element, for example a proxy server in a cellular communications network, sitting in the data path between an ABR client and an ABR server can try to exercise control over the ABR client by artificially changing the bandwidth available for the connection between the ABR client and server. For example, if the intermediate network element reduces the bandwidth available for the data being download from a server to the ABR client, if possible, the ABR client will react by requesting lower quality segments. An intermediate network element may act in this way in order to prevent an ABR client consuming too much network resources.
However, in some circumstances, the ABR client may not be able to request segments that have a quality level that is low enough to ensure that they can be delivered to the ABR client over the reduced bandwidth connection quickly enough so that the video can be played without stalling. For example, sometimes, there may be not be segment variants available at the server that can be delivered in a timely fashion to the ABR client at the bandwidth set by the Intermediate network element. Alternatively, it is known that some ABR clients are configured in a ‘non-adaptive mode’ in which they can select to request only one type of segment variant and so cannot adapt to a reduced bandwidth.